1. Field of the Invention
The present invention relates generally to software and hardware integration, and more particularly to the integration of independent software and hardware products in safety-critical, mission critical, or other regulated applications.
2. Description of the Related Art
The development of highly complex systems typically involves the use of multiple specialized vendors to design and manufacture specific, stand-alone components that are then integrated into the system. Unless an industry standard has been adopted, each stand-alone component is often developed using a proprietary and/or unique interface protocol. To integrate such components, customized interfaces must be developed, tested, and in certain applications, certified. The complexity of the integration effort is further increased where the same component needs to be integrated with multiple disparate platforms.
The complexity of integrating components into sophisticated systems can lead to the development of ad hoc architectures. Popularly called “stovepipes,” such systems use point-to-point integration and can lack coordination and planning across multiple systems. Thus, prior integration efforts are often duplicated and the resulting system can suffer with a costly, unmaintainable, and unextendable architecture.
The impact of such systems is perhaps most strongly felt in areas of safety-critical or mission-critical development, such as avionics, defense, and medical, as well as applications requiring high reliability, determinism, robustness or continuous availability. The need to satisfy strict industry testing and certification regulations can turn the process of replacing or upgrading a mundane component into a substantial implementation-specific development effort, resulting in additional costs and time delays.
FIG. 1 depicts an example of the prior art process 100 of integrating components into complex systems, such as aircraft, ships, motorized vehicles, and even robots. Although FIG. 1 is described in terms of integrating physical peripherals, a person of ordinary skill in the art having the benefit of this disclosure will understand that the discussion is equally applicable to the integration of software. In the illustrated embodiment of FIG. 1, objects 108, 110, and 112 are depicted having capabilities which make it desirable that objects 108, 110, and 112 are interchangeable with systems 102, 104, and 106. Objects 108, 110, and 112 may be, by way of example and not limitation, a group of radios, radars, sensors, actuators, or other devices or software. Systems 102, 104, and 106 are depicted as aircraft having unique and differing implementations.
Generally speaking, an implementation is the successful actualization of a technical specification or algorithm as a program, software component, or other computer system. Various implementations may exist for a given specification or industry standard, many being unique and proprietary in nature. The framework allowing a given software application, including the control code of a physical periphery, to run is specifically described by a platform, which often includes a combination of the operating system (OS), programming languages and related runtime libraries, and user interfaces. The relationship between hardware components comprising a system and their individual properties is similarly described by the system's hardware and software architectures and focuses on managing and controlling dependencies. Thus, the integration of an object, either physical or virtual, having control code designed for one implementation into a system designed for another implementation involves the use of an interface having an architecture capable of managing the interactions between the object and system as well ensuring proper interpretation of commands.
Thus, for example, the integration of object 108 into systems 102, 104, and 106, can require the development of three separate interfaces, one for each system. Because the driving force of each integration effort is the characteristics of the given system, the architecture of each resulting interface can be fragile and limited in terms of reusability or adaptability. Therefore, although objects 110 and 112 are similar in terms of function, little of the development effort that went into creating the interfaces for object 108 can be reused or modified in integrating objects 110 and 112 with systems 102, 104, and 106. The ultimate result is the undertaking of nine duplicative, costly and time consuming, implementation-specific design efforts (illustrated by the connecting lines in FIG. 1) to integrate each object with each system. Where the systems are for use in safety-critical, mission-critical, or other regulated applications, each object-system implementation may further require verification and certification before release, with the extensive testing required further increasing costs and time delays.
Therefore, there is a need to develop an architecture allowing non-system and non-component specific integration of elements, where the architecture is verifiable, certifiable, and reusable within a given industry.